Technical Definitions
A relation may be a two dimensional table. Also the relation may be a view, e.g. a materialized view. The relation includes rows and columns. The columns of the relation are named by attributes.
A view may be understood as a relation defined by a computation, e.g. a query over one or more stored relations (e.g. tables). A materialized view may be constructed periodically from a database, e.g. via a query, and stored in the database.
A database may be understood as a collection of data, possibly managed by a database management system (DBMS).
A schema or database schema may specify the logical structure of data in a database. The schema may specify one or more relations. The schema may also include one or more of the following: assertions, triggers, system defined data types or sets of values, and user defined data types.
The database may include one or more schemas, as well as object oriented functionality.
A database operation may include relational or object oriented database operations. The database operation may be understood as a command, possibly issued by a user using a data manipulation language, that affects either the schema or the content of a database; also or alternatively, the database operation could also extract data from the database. The database operation may be processed by a DBMS. Examples of database operations include queries made against the database, inserting rows in a relation, deleting or updating rows in a relation, etc.
An action may comprise one or more database operations. In some cases, the action may be a complex function carrying out significant application processing (e.g. synchronization) in addition to database operations.
An application database may be associated with multiple applications. An application database may also be associated with a single application.
Processing a request may include executing multiple applications, wherein each application performs a distinct set of functions and differs from any of the other applications. Each application may have a corresponding database that differs from any database associated with any of the other applications. Calculating the duration of a processed request may include determining how long each application is executed during the processing of the request as well as determining the duration of each action carried out by each of the executed applications.
A primary order identifier may be associated with all requests used to process an order. The primary order identifier may be a key, e.g. a unique key or primary key, of an application database. In a specific example, the primary order identifier may be implemented as a Siebel order ID. The primary order identifier may be used to track an order across a number of databases.
A request is received by an application. Processing the request may require performing one or more actions. Examples of requests are create order, create account, submit order, change order, and cancel order. Each type of request (e.g. create order may be considered a type of request) may require a different set of actions to complete. Some requests may be the same across multiple orders, other requests may differ for each order.
Processing an order may comprise fulfilling (or processing) a plurality of requests, where all requests fulfilled to process the order may be associated with the same primary order identifier.
A proper subset of a particular set is a subset that is strictly contained in the particular set. Accordingly, the proper subset necessarily excludes at least one member of the particular set. For example, the set of natural numbers is a proper subset of the set of rational numbers.
A condition may evaluate to true or false and may include comparison operators and logical operators. The condition may include further operators such as pattern matching operators.
A key may be implemented as a unique key or a primary key. Other implementations are also possible. The unique key uniquely identifies each row of a relation and comprises a single column or a set of columns. A primary key is a special case of unique key, such that a table can have at most one primary key and the primary key may not be null.
Times may be provided in a standard format, e.g. as timestamps. For example, a time may be represented as the number of seconds since the Unix epoch.